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ABSTRACT 



ToonTalk is an animated interactive world inside of which 
one can construct a very large range of computer programs. These programs are 
not constructed by typing text or arranging icons, but by taking actions in 
this world. Robots can be trained, birds can be given messages to deliver, 
and so on. This paper describes the design and preliminary testing of an 
interactive puzzle game that functions as a ToonTalk tutorial. Children are 
presented with a series of interactive puzzles in a game- like narrative 
context. The puzzles gradually introduce programming constructs and 
techniques. Each puzzle presents the player with a very limited selection of 
ToonTalk objects. Even some very young children are able to solve the puzzles 
because the search space is so strongly constrained, and yet players do not 
behave as if the puzzles are too easy- -the children are clearly challenged. 
The sequence of puzzles is carefully designed to gradually introduce new 
concepts, one at a time. Testing has shown that both children and adults 
enjoy the puzzles and have learned some sophisticated programming skills. 
(Contains 11 figures and 7 references.) (Author/AEF) 
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ToonTalk™ is an animated interactive world inside of which one can construct a ver 
large range of computer programs. These programs are not constructed by typing 
text or arranging icons, but by taking actions in this world. Robots can be trained 
f' fan be given messages to deUver, and so on. ToonTalk has been described at' 
NECC 95 (Kahn, 1995) as well as (Kahn, 1996a & 1996b). 



This paper describes the design and preliminary testing of an interactive puzzle game 
that functions as a ToonTalk tutorial. Children are presented with a series of 
interactive puzzles in a game-like narrative context. The puzzles gradually introduce 
programming constructs and techniques. Each puzzle presents the player with a very 
limited selection of ToonTalk objects. Even some very young children are able to 
solve the puzzles because the search space is so strongly constrained. And yet 
payers do not behave as if the puzzles are too easy— the children are clearly 
challenged. The sequence of puzzles is carefully designed to gradually introduce new 
concepts, one at a time. Testing has shown that both children and adults enjoy the 
puzzles and have learned some sophisticated programming skills. 
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Introduction to ToonTalk™ 

ToonTalk is a programming "language" whose source code is animated (Kahn, 1995). 
(ToonTalk is so named because one is "talking" in (car)toons.) This does not mean 
that it is a visual programming language where some static icons have been replaced 
by animated icons. It means that animation is the means of communicating the 
entire meaning of a program to both humans and computers. One programs in 
ToonTalk by directly manipulating objects in a virtual animated world. If, for 
example, one needs to swap the values of two locations, what can be more natural 
and easy than grasping the contents of one, setting it down, grasping the contents 
of the other, placing it at the first location, and then moving the original item to 
the second location? (See Figures 2-6.) This is something a very young child can 
understand and do, while only a programmer can write the equivalent code. (See 
Figure 1.) 

temp = x; 
x = y; 
y = temp; 

Figure 1. Swapping two items in C 




Figure 6 



Figures 2-6. Snapshots of the creation of a ToonTalk program to swap two items 
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Computer scientists strive to find good abstractions for computation. In ToonTalk a 
critical goal is to find good "concretizations" of those abstractions. The challenges 
are twofold: to provide high-level powerful constructs for expressing all programs 
and to provide concrete, intuitive, easy-to-learn, systematic game analogs to every 
construct provided. 

The ToonTalk world resembles a twentieth-century city. There are helicopters, trucks, 
houses, streets, bike pumps, toolboxes, hand-held vacuums, birds, boxes, and robots. 
An entire ToonTalk computation happens in a city. Most of the action in ToonTalk 
takes place in houses. Homing pigeon-like birds provide communication between 
houses. Birds accept things, fly to their nest, leave them there, and fly back. 
Typically houses contain robots that have been trained to accomplish some small 
task. A robot is trained by entering into his "thought bubble" and showing him what 
to do. The robot remembers the actions in a manner that can easily be abstracted to 
apply in other contexts. 

The behavior of a robot is exactly what he was trained to do by the programmer. This 
training corresponds in traditional terms to defining the body of a method or clause. 

• sending a message by giving a box or pad to a bird, 

• spawning a new process by dropping a box and a team of robots into a 
truck (which drives off to build a new house), 

• performing simple primitive operations such as addition or 
multiplication by building a stack of numbers (which are combined by 
a small mouse with a big hammer), 

• copying an item by using a magician's wand, 

• terminating an agent by setting off a bomb, 

• changing a tuple by taking items out of compartments of a box and 
dropping in new ones. 

Figure 7. Possible actions of ToonTalk robots 

When the user controls the robot to perform these actions, she is acting upon 
concrete values. This has much in common with keyboard macro programming and 
programming by example (Smith, 1975). The hard problem for programming by 
example systems is how to abstract the example to introduce variables for generality. 
ToonTalk does no induction or learning. Instead, the user explicitly abstracts a 
program fragment by removing detail from the thought bubble. The preconditions 
are thus relaxed. The actions in the body are general since they have been recorded 
with respect to which compartment of the box was acted upon, not what items 
happened to occupy the box. 

The ToonTalk Puzzle Game 

A carefully designed sequence of puzzles can be pedagogically very effective. A series 
of puzzles is more appealing to most children when it is embedded within a nanative 
adventure. The ToonTalk puzzle game starts with a brief "back story." An island is 
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sinhng and a friendly Martian named Marty happens to be flying by and rescues 
everyone. He is nearly done when he crashes and is hurt. The player has volunteered 
to rescue Mai^. Marty, because he is hurt (you can see his arm in a sUng and his 
bruises , can t get out and build the things needed to fix his ship. So he asks the 
player to make things for him. The player goes nearby where the components he or 
she needs can be found and has to figure out how to combine them. When stuck or 

ITllT/T "" hints or 

.f stuck on a particular problem then Marty gives the 
^ detailed instructions so he or she can proceed to the next puzzle. Note that 

So dX r. ^ fits the nanauve atnictuie since Marty knows 

wnat to do but is too badly injured to do it himself. 

In order to fix Marty's ship, the first job is to fix the ship's computer. The computer 

Zbers“ h'h 1 ? "he first level is to generate the 

numbers needed. The culmination of the level is the construction of a program that 

computes powers of two (1, 2, 4, 8 and so on to 2 to the thirtieth power) The next 
evel involves the construction of a program that computes the alphabet. The next 
task IS to the ship s clock. Solving these puzzles involves measuring time 
mathematics, and some new programming techniques. At one point, the player has 



A Detailed Look at Some Programming Puzzles 

It is instrucbVe to look at some puzzles in detail. The first real program a player 
puzzle. Marty needs a number bigger than 1,000,000,000 for 
the computer When the player goes into the room all she finds is a box with the 
nuinber 1 in it, and a robot with a magic wand capable of copying things. The player 
needs to train the robot to repeatedly double a number. Several of the earUer pSes 
for this task. The first three puzzles introduce numbers, additioi, 

1,000 (see Figure 8). When the player goes next door, on the floor is just the number 

the"numL’I‘of 5 tv" something with 

notWn^^Jrt the wand. It turns out that in this context there is 

nothing that can be done with the number. Marty has already informed the player 

that pressing the space bar will turn on the wand. Even children as young as s J 

soaZ tip over the number, hit the 

' S^tW 1 the number on the floor 

h 3 m J* 1 ^Ti, V u entertaining way, by a Uttle mouse with a big 

"^®P®^tedly copy the number and add it to ^ 

fcounSr^i-^ ^‘^‘^'tion, the magic wand has 
a counter that is initially set to 10. After 10 copies, it has run out of magic and 

won t work anymore. This helps constrain the search for a solution. (This is not an 

^ i^tially make the 

^s ake of mahng many copies and then adding them.) The solution requires the 

Avoiding such tedium is a motivation for 
programnung robots to do the work for you. 
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Figure 8. The injured alien introducing the fourth puzzle 




Figure 9. The initial state of the fourth puzzle 




Figure 10. Using the Magic Wand to copy a number during the fourth puzzle 

Just before the ninth puzzle, the player is introduced to robots and builds her first 
program. This puzzle is very simple. Marty needs a box with two zeros in it. When 
the player goes next door, she sees a robot with a magic wand and a box with one 
zero in it (see Figure 11). The wand is stuck to the robot and can't be used to copy 
the box. Most players discover that you can give the box to the robot (and those 
that don't, do so soon after getting hints from Marty). When they do, they see an 
animation of the thought bubble of the robot expanding and the player is now 
controlling the robot and the box with one zero in the robot's thought bubble. 
Nothing else is there, so most players try to train the robot to copy the box. The 
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robot started off with a very small memory— only enough to remember two steps. 
When the player trains the robot to copy the box and then join the copy with the 
original box, the robot's memory is full so his thought bubble shrinks back down and 
the player is back on the floor with the robot and the box. The robot now knows 

what to do when given a box, so it repeats what it was trained to do and copies the 
box. 

These early puzzles are designed to simplify some programming tasks. For example, 
the player doesn't need to know how to terminate the training of a robot. When the 
limit on the number of steps the robot remembers is exceeded, his training is 
automatically terminated. Similarly, the counter on the magic wand ensures that the 
robot will stop after the correct number of iterations. In later puzzles, these tasks 
become the player's responsibility. 




tecTiC^cjc 

ttiiCsGsC 



Figure 11. The initial state of the eighth puzzle 



By the time the pUyer starts the ninth puzzle, he or she has performed the 
prerequisite actions and must combine them properly to train a robot to repeatedly 
double a number. The player is presented with a robot holding a wand good for 30 
copies and a box with a 1 in it. Again the robot is limited to remembering only two 
step programs. Because there is only the robot and the box to work with, and 
because of the limitations imposed on the robot, this otherwise overly ambitious 
early programming example can be solved by most players with few or no hints. And 
yet, the constraints do not make the puzzle trivial— experimentation, thinking, and 
problem solving are necessary to solve the puzzle. 



The Pedagogical Importance of the Puzzle Game 

There are many ways in which children can learn to program (Kahn, 1998). Typically, 
the most effective is by many one-on-one sessions with a very knowledgeable and 
skilled teacher. Unfortunately, such teachers are in short supply. On the other hand, 
some children learn well by a self-directed exploration of ToonTalk in free-form 
mode. However, they seem to be the minority. Most children ask what they should 
do next rather than explore on their own. For them the puzzle game is ideal. They 
find it fun and challenging but don't feel lost. A good series of puzzles actually leads 
a player step by step where the puzzle designer wants to go. The players don't feel as 
if they are being led anywhere but have the illusion that they are in control. The 
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puzzles so constrain the set of objects that can be used and how they can be used 
that the player has only a few choices. 

Even among those children for whom the puzzle game is well suited, there is 
variation from those that want to figure out everything themselves to those who 
very quickly want hints. The ToonTalk puzzle game deals with this by keeping Marty 
in another place. If you come to him empty handed or with the wrong thing, he will 
give you a hint. Each time you return during the same puzzle you get a more 
revealing hint until eventually you get detailed instructions from Marty. This 
behavior accommodates a wide range of learning styles. 

In addition to free form exploration and the puzzle game, ToonTalk also includes 
demos. Here the child can observe a playback, with synchronized nanation, of the 
demonstration of some programming construct or technique. This passive viewing 
has its place for many children but the learning is typically superficial unless 
followed by puzzle solving or free form construction. 

An automated intelligent tutor (Selker, 1994) is another approach to teaching 
programming. As the user performs actions, the tutor maintains a user model and 
attempts to tutor the user. In ToonTalk's free-form mode, Marty can play the role of 
a tutor. He maintains a database of which actions the user has performed and 
suggests new ones. The suggestions are based upon what the user is currently doing 
and what he or she has already done. This kind of tutoring has worked well with a 
minority of the testers. It is a good complement to the other learning modes. A 
much more sophisticated automated tutor would presumably be much more effective 
but much more difficult to implement. 



Testing 

The puzzle game of ToonTalk has been tested with two classes of 24 children in a 
fourth grade class in Menlo Park, California. Each pair of children was observed using 
ToonTalk for three, 40-minute sessions. No formal testing was performed but nearly 
all the pairs of children solved the first 25 puzzles without assistance. The children 
had no prior exposure to ToonTalk and only two had any prior exposure to computer 
programming. 

The ToonTalk puzzle sequence has a "self-testing" character. Puzzle Number 15, for 
example, is a difficult programming task for novices — generating a data structure 
containing 1, 2, 4, 8, and so on up to 1,073,741,824. The prerequisite knowledge for 
constructing such a program was acquired in solving Puzzle 9 (constructing a 
program to compute 2 to the 30th power) and Puzzle 13 (constructing a data 
structure filled with zeros). These puzzles, in turn, rely upon having learned in 
earlier puzzles how to double a number and how to train robots (construct 
programs). The fact that the children succeeded in solving the puzzles indicates that 
the puzzles have succeeded and the children are learning computer programming. 

There is also a beta version available on the Internet (see http://www.toontalk.com) 
and testers around the world have worked with the puzzles. The resulting anecdotal 
evidence is that a wide range of people can work through the puzzle sequences. For 
example, a 6-year-old boy in Colorado solved the first 25 puzzles. He was not able to 
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read, however, and required an adult to read the text. ToonTalk has since been 
augmented with a text-to-speech capability so even that kind of help is no longer 
necessary. Another example is a 25-year-old woman with no programming experience 
who solved all 62 puzzles on her own. 

Related Work 

Rocky's Boots and Robot Odyssey were two games from The Learning Company in the 
eaily 1980s ^at exdted many computer scientists. In these games, one can build 
arbitrary logic circuits and use them to program robots. This is all done in the 
context of a video game. The user persona in the game can explore a city with robot 
helpers. Frequently, in order to proceed, the user must build a logic circuit for the 
robots to solve the current problem. The design of ToonTalk and its puzzle game 
were inspired by Robot Odyssey. The most important difference is that ToonTalk is 
capable of supporting arbitrary user computations— not just the Boolean 
computations (AND, OR, and NOT) of Robot Odyssey. 

Many computer and video games use puzzles as an effective and fun tutorial. 
Lemmings and The Incredible Machine are two good examples that inspired the work 
reported here. Scott Kim (1995) has written about puzzle design and the pedagogic 
role of puzzles. 

In the last 15 years, there have been several attempts to build intelligent tutors that 
can teach programming (e.g., (Selker, 1994)). This approach has its place in the pool 
of pedagogic tools but requires a much stronger external motivation for learning 
programming. The ToonTalk puzzle game is fun— children play it for pleasure, in 
some case without even knowing that they are learning computer-programming 
skills * 



Discussion 



The design and informal testing of a sequence of interactive puzzles designed to 
teach programming concepts and techniques has been presented. This work raises 
many questions. Is the technique limited to animated or visual programming 
languages? Could a similar puzzle sequence be designed for LOGO or Java? How does 
a puzzle sequence differ from a more traditional problem set? 

- Let us try to imagine a puzzle sequence for LOGO. The equivalent of the ToonTalk 
puzzle constraints would be to present the player with "TO", 3 "+"s, a "1", 2 
variables, etc. and ask them to compute a number greater than 1,000. Such puzzles 
might be as intellectually challenging as the ToonTalk puzzles, but probably would 
be harder and less fun. They would be harder because of a lack of direct 
manipulation and instant feedback. They would be less fun because it is hard to add 
the element of narrative and characters that is central to the ToonTalk puzzles. As a 
result, such puzzles would probably feel more like problem sets. The puzzles in 
ToonTalk don't just test a student's skills and knowledge, but teach. This is because 
the student is placed in an environment where they can safely explore a large, but 
not too l^ge, space of possibilities. And the exploration is immediate— every ' 
intermediate step they take has direct, visible, and audible effects. 
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Future Work 



The testing to-date has not been formal and precise. We hope to find and collaborate 
with another group interested in studying the effectiveness of these puzzle 
sequences, in a more formal manner. 

Other puzzle sequences can be imagined that would teach different computer 
programming topics, like concunency, algorithms, user-interface design, and 
distributed systems. Puzzle sequences can be designed for specialized domains like 
computer music, game programming, or database prograiruning. The dream 
underlying this research is that learning hard topics, like computer programming, 
can be made more effective and fun by bonowing ideas from video and computer 
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